This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the 
original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 

IMAGES ARE BEST AVAILABLE COPY. 



As rescanning documents will not correct images, 
please do not report the images to the 
Image Problems Mailbox. 



(19) 




EuropfilseKM Patentamt 
Eur pean Patent Office 
OTfiee europeen dee brevets 



(12) 



(43) Date of publication: 

2a0&1997 Bullelln 1997/34 

(21) Application number: 97850016.5 

(22) Date of filing: 05.02.1997 



(11) EP 0 790 558 A1 

EUROPEAN PATENT APPLICATION 

(51) lntCI.«: G06F 11/14 



(84) Designated Contracting States: 


(72) Inventors: 


DE FR GB SE 


• Todorovlc, Zoran 




3098 Sehllern (CH) 


(30) Priority: 06.02.1996 08 597342 


• Nlieeon» Ingvar 




141 37 Huddlnge (SE) 


(71) Applicant: TELEFONAKTIEBOLAGET LM 




ERICSSON 


(74) Representative: Norin, Kias et al 


126 25 Stockholm (SE) 


Telefonaktlebolaget L M Erieeson 




Patent and Trademark Department 




126 25 Stockholm (SE) 



(54) Method and system for faet recovery of a primary store database 



(57) The present invention provides an electronic 
data storage and processing system where non-persist- 
ent memory such as random access memory (RAM) 
stores a database with a firet memory section storing 
eemi-permanent data and a second memory section 
storing transient types of data. A third memory section 
in RAM may be used to buffer database transactions 
relating to the semi-permanent data stored in the first 
memory section ot RAM. At periodic and appropriate 
checlqpoint time inten^ats, the semi-permanent data cur- 
rently stored in the first section of RAM are copied or 
"dumped" onto persistent (disk) memory. Only those da- 
tabase transactions that affect the semi-permanent data 



stored In the first section of RAM occurring after the most 
recent checicpoint *dump' are togged onto persistent 
memory. Database transactions affecting the transient 
type o1 data stored in the second portion of RAM are not 
logged. A recovery processor recovers from a systeni 
failure by reloading semi-permanent data from the per- 
sistent memory into the first section of RAM and execut- 
ing the log. However, in one embodiment, the recovery 
processor may leave the data in the second section of 
RAM in the state in which that data exists after the sys- 
tem failure. Considerable time is saved by not loggirig 
transient database transactions or executing a tog for 
those transactions when recovering from a system fail- 
ure. 
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Description 

RELD F THE INVErmON 

The present inv ntion relates to a method and sys- 
tem for database recovery, and more particutarty. to re- 
covering a primary store database where at least a por- 
tion of the contents of the database fluctuate frequently 
over time and/or vwhere large volumes of data have to 
be recovered. 

BACKGROUND AND SUMMARY OF THE 
iNVENTION 

From the standpoint of an operating system, a da- 
tabase system carries out transactions to manage the 
creation, deletion, and modification of "records" stored 
in the database. One example of a transaction in a mo- 
bile telephony application is registering a new ceil loca- 
tion of a "roaming" mobile radio telephone, i.e., the radio 
has moved from geographical cell area 1 to geographi- 
cal celt area 2. More formally, a database transaction 
describes a specified sequence of operations that be- 
gins with what Is sometimes referred to as a "begin" op- 
eration and ends with what is sometimes referred to as 
a "commit" operation or possibly with a "roll back" or 
"at)ort" operatbn. A commit operation signals success- 
ful termination of the transaction; a roll back/abort oper- 
ation signals unsuccessful tenmination of the transac- 
tion. Accordingly, a transaction either succeeds or fails. 
If the transaction fails, nothing in the database should 
be changed. 

In transaction-oriented database management sys- 
tems, a recovery nnanagernnaintains the "atomic* nature 
of transactions and reestablishes system operation up- 
on system failures. Failures may have their source in 
fiardware or software. Examples of failures might in- 
clude failure of the memory medium on which the data- 
base is recorded, failure of the computing system in 
which the database management system is operating 
resulting for example from a programming error, or fail- 
ure of one or more transactions to successfully complete 
processing. Some failures, such as the loss of power, 
result in loss of knowledge by the system as to its own 
state, the state of processes under its control, and infor- 
mation with respect to changes/updates being made to 
the database. 

In order to recover from failures, database manage- 
ment systems generally provide a checkpoint and jour- 
nal/log technique. A checkpoint triggers the copying of 
the database contents from non-persistent media like 
random access memory (RAM) onto persistent media 
such as a magnetic disk at periodic but usually infre- 
quent intervals of time. This periodic copying is some- 
times referred to as a "dump." A mechanism is required 
to ensure that database transactions which occur be- 
tween checkpoint "dumps" to persistent media are re- 
c rded "serially" on a journal or log. The joumalled or 



logged data is sometimes raf erred to as "delta" informa- 
tion. The logged transactions may be stored in blocks 
in non-persistent storage buffers, and when the tog buff- 
ers are full or at the end of relatively short tim int rvais, 
s the logged transactions are written into persetent me- 
dia. 

While the contents of the database and log buffers 
in the prtntary, non-persistent media store may be tost 
during a system failure, the infomnation stored on per- 
sistent media is usually not damaged and is used to re- 
store most of the datatmse information. Those database 
transactions in progress at the time of the failure which 
were not logged must be "rolled back" because th y 
ware notf ully completed. In order to identify which trans- 
actions to roll back, the log^oumal is searched so that 
at system restart time, the recovery manager can deter- 
mine both the transactions that need to be "undone" to 
effect "roll back" and the transactions that need to be 
"redone" to effect "commit" in order to serially restore 
the database to a correct and consistent state. 

In practice, the recovery manager may atari with 
two lists: an undo list and a redo list. The undo list Initially 
contains all logged transactions active at the time of the 
most recent checkpoint, and the redo list is initially emp- 
ty. The recovery manager serially searches forward 
through the journal/log starting from the checkpoint 
record. If the recovery nmnager finds a "begin" transac- 
tion record for a given transaction, it adds that transac- 
tion to the undo list. If the manager finds a "commit" 
record for a given transaction, it moves that transaction 
from the undo list to the redo list. When the recovery 
manager reaches the end of the k^g, the undo list and 
the redo list identify, respectively, those transactions 
that must be undone and those which must be redone. 
Thereafter, the recovery processor goes through the 
log. serially redoing the transactions on the redo list and 
undoing the transactions on the undo list. 

A significant prc^lem with this recovery procedure 
is that new transactions cannot be accepted during the 
time that the database is being recovered. Until the re- 
covery process is complete, many update transactions 
are lost. Another significant problem for systems with 
large announts of data stems from the Infrequent occur- 
rence of datalaase image dumps from non-persistent 
media to persistent media. Thus, the number of recov- 
ery log records that must be maintained to recover for- 
ward from a most recent image dump/checkpoint grows 
with time and can become quite large. The larger the 
log. the longer It takes to recover from a system failure. 

A number of patents relate to methods for trying to 
obtain consistency between the checkpoints and the log 
including, for example U.S. Patents 4,507,751; 
4,868.744; 5.278.982; 5,043.866; 5,333.303; 
5.386.554; and 5.414.B40. Most of these patents do not 
concern themselves, however, with the size of the log 
or the considerable time it takes to recover from a fault. 
U.S. Patent 5.278,982 acknowledges the need for an 
efficient recovery tog archiving protocol but addresses 
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this problem using a pseudo-crash recovery technique 
that fitters and discards most und log records during 
the tog archiving proc ss. But the filtering of non-essen- 
tial records takes place after those non-essential 
records have already been logged. 

It is an object of the pr s nt invention to r ducethe 
volume of the recovery log archive and the time needed 
for recovery. Thus, it is an object of the present invention 
to provide a fast and efficient database recovery of a 
primary store. 

The present inventbn establishes two different cat- 
egories of data including semi-permanent data and tran- 
sient data. Semi-permanent data may include data 
which change relatively infrequently or rK>t at all. Semi- 
permanent database transactions may be handled us- 
ing the conventional checkpoint and logging techniques 
described, for example, in the above-identified patents. 
Trcmsient data are typically updated with high frequency. 
In additbn, transient data may be of the type where 
some inconsistency in that data can be tolerated by the 
application which uses that data. Database trBn8actk>n8 
that involve transient data are not logged. 

Certain kinds of database applications may be par- 
ticularly well-suited to classifying data transactions into 
semi-permanent and transient. For example, consider 
a mobile telephone database application which contains 
a database of the location of mobile telephony subscrib- 
ers. Semi-permanent database records may relate to a 
relatively static mobile subscriber profile, i.e., the sub- 
scriber's identffication, his telephone number, services 
subscribed to, etc. In general, euch a subecriber profile 
changes only infrequently or not at all. However, ether 
more dynamic information relating to that mobile sub- 
scriber may be defined by the mobile telephony appli- 
cation as transient data, e.g., the subscriber's current 
location in the mobile telephony system. When a mobile 
radio subecriber changes his te>cation, this new location 
is registered in the database. If such mobile subscriber 
location changes were logged using conventional log- 
ging mechanisms, such togging files would be extremely 
large. Moreover, given the considerable amount of time 
required to recover large logging files, it is likely that 
many subscritsers will have already changed their loca- 
tion during that recovery process. 

The recovery time in this kind of situation may be 
quite lengthy, especially where a very large log file is 
maintained and where the recovery process restores all 
locations even though only the most recently logged lo- 
cation is of any interest Since no data transactions are 
accepted during whatever amount of time the recovery 
process takes, reducing that recovery time means that 
fewer transaction updates are lost. 

The present invention provides an electronic data 
storage and processing system where non-persistent 
memory, such as random access memory (RAM), stores 
a database divided into first and secc»id memory sec- 
tions for storing semi-permanent types of data and tran- 
ei nt types of data, respectively. A third memory ection 



in RAM is used as intermediate storage, i.e.. a logging 
buffer, for logging database transactbns relating only to 
the semi-permanent data stored in the first memory sec- 
tion of RAM. A first persist ntm nrwry, such as magnetic 
s disk, stor s a copy of the s mi-perman nt data etor d 
at an earlier time in the first section of RAM. 

At periodic and appropriate checkpoint time tnt r- 
vals, the operating system copies the current data 
stored in the first section of RAM into the persistent disk 
10 memory. In addition, the operating system logs only 
those database transactions that affect the semi-perma- 
nent data stored in the first section of RAM occurring 
after the most recent checkpoint 'dump.' In other words, 
database transactions updating the semi-pemnanent 
IS ciata that have occurred since the most recent dump are 
stored in a persistent memory "log." Database transac- 
tions affecting the transient type of data stored in th 
second portion of RAM are not logged. Moreover, th 
operating system may archive only the semi-permanent 
data stored in the first section of RAM in the persistent 
disk memory. However, in an altemative embodiment, 
even though transient data updates are not logged, the 
current transient data in the second memory section 
may also be dumped into the persistent disk at each 
checkpoint. One way of classifying data as seml-penma- 
nent data or transient data is that semi-permanent data 
usually changes over a time period greater than the 
checkpoint time interval while the transient data chang- 
es more frequently, and oftentimes, during the time pe- 
riod between two checkpoints. 

A recovery processor recovers electronic data stor- 
age and processing systems from a system failure by 
copying semi-permanent data from the persistent disk 
memory over the data currently held in the first section 
of RAM after the failure. In contrast, the recovery proc- 
essor leaves the transient data In the secorKl section of 
RAM in the state that data exists after the system failure. 
In an altemative embodiment where the transient data 
are dumped to persistent storage, the transient data in 
RAM are checked tor consistency at reload. If the tran- 
sient data in RAM are consistent, the transient data in 
persistent storage are not reloaded. If the transient data 
in RAM are not consistent, the transient data in persist- 
ent storage may be loaded into the second portion of 
RAM at recovery. That way the transient data are con- 
sistent even though possibly outdated. 

The present invention also provides a method for 
nnanaging the data handling system. Database transac- 
tions relating tosemi-permanent data are stored in afirst 
section of the non-persistent memory. Database trans- 
actions relating to transient data are stored in a second 
section of the non-persistent memory. At predetermined 
checkpoint time inten^als, the data in the first section of 
non-persistent memory are copied into the persistent 
backup mennory. In an alternative embodiment, the tran- 
sient data rnay also be copied Into persistent memory 
at checkpoint intervals and used to recover consistent 
(but old) transient data sh uld the transient data stored 
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in RAM bacorne inconsistent. Just those database 
transactions affecting the semi-permanent data stored 
in th first section of non-persistent memory, but which 
occur after the most r c nt checkpoint "dump," ar 
stor d in a tog portion of persistent memory. Database ^ 
transactions that affect the transient data are not logged. 

Considerable time and data processing resources 
are saved tf only the semi-permanent of data are stored 
in persistent memory and only database transactions af- 
fecting the semi-permanent data are logged. With the 10 
amount of data that must be copied back into the non- 
persistent memory from the persistent memory and then 
updated using the logged database transactions being 
reduced because the transient data are not involved in 
this recovery process, the time required to recover from 1^ 
a system failure is considerably reduced. In addition, the 
shear volume of data that must be logged and archived 
is decreased which makes for a more efficient data han- 
dling system even in the absence of a system failure. 

The foregoing, together with other features and ad- zo 
vantages of the present invention, will become more ap- 
parent when referring to the following specification, 
ciaimG. and the accompanying drawings. 

BRIEF DESCRIPTIOM OF THE DRAWIISiGS 2S 

For a more complete understanding of the inven- 
tion, reference is now made to the following detailed de- 
scription of the embodiments illustrated in the accom- 
panying drawings wherein like reference numerals refer so 
to like elements throughout the drawings: 

FIGURE 1 illustrates a data handling and storage 
configuration for storing, updating, togging, and se- 
lectively archiving different types of data; 35 

FIGURE 2 illustrates a recovery process for the da- 
ta handling and storage configuration shown in FIG- 
URE 1; 

40 

FIGURE 3 is a function block diagram of a data han- 
dling and recovery system in accordance with the 
present invention; 

FIGURE 4 illustrates different types of database ^ 
transactions that may have to be dealt with at sys- 
tem failure; 

FIGURE 5 illustrates a database system failure and 
recovery time-line; so 

FIGURE 6 is a flow chart diagram illustrating a da- 
tabase transaction handling procedure in accord- 
ance with the present invention; and 

FIGURE 7 Is a flow chart diagram of a recovery pro- 
cedure for recovering failure of a database system 
in accordance with the pres nt inventi n. 



DETAILED DESCRIPTIOM OF PREFERRED 
EaflBODIRflEWT3 

In the following d scription, for purposes of expla- 
nation not limitation, specific details are set forth such 
as particular techniques and configurations to provide a 
thorough understanding of the present invention. How- 
ever, it wilt be apparent to one skilled in the art that the 
present inventbn may be practiced in other embodi- 
ments that depart from such specific details. In other in- 
stances, detailed descriptions of welt known methods 
and devices are omitted so as not to obscure the de- 
scription of the present inventbn with unnecessary de- 
tail. 

FIGURE 1 shows a data etoiage and handling con- 
figuration for storing, updating, and selectively archiving 
different types of data. A "primary store" database 1 0 is 
a non-persistent memory such as random access mem- 
ory (RAM) that stores a datatsase. Data stored in non- 
persistent memory such as RAM is lost when power t 
that memory is removed even if only for a very short pe- 
riod of time. Primary store 1 0 is divided into three mem- 
ory sections 1 4, 1 6, and 1 8. Of course, memory sections 
could also be separate memories tf desired. The first 
section of memory 14 stores a first type of data such as 
semi-permanent data. Semi-permanent data may in- 
clude data which a particular application changes rela- 
tively infrequently or not at all. The second section 16 
of the primary database 10 stores a different category 
of data referred to as transient data. In contrast with 
semi-permanent data, transient data may change (but 
not necessarily) with higher frequency. However, semi- 
permanent data and transient data are used throughout 
this description as non-limiting examples of two catego- 
ries of data which are handled differently during data- 
base updating and system failure recovery procedures. 
Of course, other categories of data are also encom- 
passed by this invention. An optional but preferable third 
section 1 6 of the primary store database 10 is a log buff- 
er for intemiediate storage of database transaction up- 
dates that occur after a most recent checkpoint time in- 
terval. The tog buffer 16 is enr\ployed to make the input/ 
output transfer of transaction updates from RAM to disk 
more efficient. 

At each checkpoint time interval, the contents of the 
semi-permanent data stored in the first memory section 
1 4 are "dumped" or copied into persistent storage media 
20 which may be, for example, a magnetic disk or tape. 
In addition, the information in the tog buffer is transferred 
(preferably frequently) into a persistent memory log 22 
which may also be magnetic disk or tape. Significantly, 
the transient data in the second memory section 16 are 
in one embodiment of the invention not dumped or cop- 
ied to any persistent storage media. Instead, transient 
data may have been determined by an application using 
the database to change with sufficientty high frequency 
that it is not effective or efficient to dump that transient 
data into persist nt storage b cause it is likely that the 
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values of that transient data will change soon after the 
dump occurs. In other words, to effectiv »y "bacic up' this 
transient data so that It coutd be used to restore the da- 
tabase in the event of a system failure, th backup/dump 
Inten^al would hav tob unrealistlcally small compared s 
tothech ckpoint dump Int nrals used for the semi-p r- 
manent and log buffer data. 

Another significant feature shown in FIGURE 1 is 
that although database records in all three sections of 
the primary store 10 are regulariy updated by database 
transactions, only the update transactions that affect the 
semi-permanent data in memory section 14 are logged 
in log buffer 1B. Transient data transactions are simply 
recorded in the second section of the database 16 and 
are not togged. In this way, the amount of data which is 
logged in the log buffer IB is considerably smaller than 
it would be if all database transactions were logged. 

in an alternative embodiment described further be- 
low, the transient data storage and RAM portion 1 6 may 
be dumped together with the semi-permanent data 
stored in RAM portion 14 into persistent storage media 
20 at the periodic checkpoint Intervals. However, in both 
embodiments, transient data updates are not logged. 
When the system recovers, the semi-penmanent data 
are reloaded from persistent storage media 20 into 
semi-permanent data portion 14 of RAM. This feature 
may be useful for example in situations where the tran- 
sient data do not change pariicutarly fast. 

FIGURE 2 illustrates a system failure recovery op- 
eration in accordance with the invention shown in FIG- 
URE 1 . Assuming a system failure, (e.g., a software fail- 
ure such as a program instruction fault, a hardware fail- 
ure, or loss of power), the database recovers by prefer- 
ably resetting or clearing the first memory section 14. 
Thereafter, the 'innage' copy of the semi-permanent da- 
ta stored in the persistent storage media 20 at the most 
recent checkpoint dump is reloaded into the first section 
14. Of course, the first memory section 14 need not be 
cleared before the reload. In this embodiment, the tran- 
sient data in memory section 16 are not reset/cleared; 
nor is any data reloaded into memory section 16. In 
short, the transient data in memory section 1 6 are left 
untouched (and inconsistent in the case of a power fail- 
ure). The log data from persistent log 22 are used to 
perform undo and redo operations necessary to recover 
semi-permanent data transacttons in section 14 in ac- 
cordance with well known procedures outlined in the 
background and summary section above. Although per- 
sistent storage media 20 and persistent log 22 are 
shown as separate memories for purposes of explana- 
tion, both can be implemented using only one persistent 
memory. 

By not having to reload innage data into the transient 
data second memory section 1 6 and/or by not having to 
perform the redo and undo operattons for transient data ss 
based on logged transactton updates, the database re- 
covery time in accordance with the present invention is 
c nslderably reduced. As a result, the number of unac- 



cepted transaction updates which occurred during the 
r covery proc ss are minimized. This minimal recovery 
time is particulariy important for transient data which 
may be updat d quite fr quently, and ther fore, whose 
most recent transactional updates are more lik ly to be 
lost during a longer database recovery. 

In an alternative example embodiment mention d 
above, the transient data stored in RAM portion 16 are 
dunnped together with the semi-penmanent data stored 
in RAM portion 14 into persistent storage media 20 at 
the periodic checkpoint intervals (shown as a dashed 
line in FIGURE 1 ). However, transient data updates are 
not logged. When the system recovers, the semi-per- 
manent data are reloaded from persistent storage me- 
dia 20 into the semi-permanent data section 1 4 of RAM. 
The transient data stored in RAM portion 16 are then 
checked to see if they are consistent. If those transient 
data in RAM are determined to be inconsistent, the tran- 
sient data image stored in persistent storage media 20 
are reloaded into the transient data portion 16 of RAM 
(shown as a dashed line in FIGURE 2). Thus, the re- 
stored transient data would be old but consistent. 

In this alternative embodiment, an applicatbn pro- 
grammer has the option to select whether he desires to 
have the transient data dumped and/or restored. While 
this embodiment may require some additional time if the 
transient data in RAM section 16 is determined to be 
inconsistent upon recovery, there is the advantage of at 
least having consistent (but old) transient data in the da- 
tabase. However this ennbodiment. like the above-de- 
scribed embodiment, saves considerable time at sys- 
tem recovery by not having to perfomn the redoandundo 
operations for transient data based on logged transac- 
tion updates, i.e.. by not having to execute a log for tran- 
sient data updates. 

FIGURE 3 is afunction btock diagram of adatabase 
management and recovery system in accordance with 
the present ffivention. An image dump archive stores on 
persistent storage media 20 the last copy of the semi- 
permanent data in the first section 14 of the primary 
store 10, and optionally the last copy of the transient 
data in the second section 16 of the primary store 10. 
The recovery log 22 is also stored on persistent storage 
media. Both the image dump archive and recovery log 
are connected to recovery processor 24, operating sys- 
tem 25. primary store 10, and database manager 26. 
The database manager 26 is connected to one or more 
application programs 26 which utilize information in the 
primary store database 10 in performing their applica- 
tions. The operating system 25 and database manager 
26 control the transaction-oriented data handling and 
storage system. The recovery processor 24 periomris 
the recovery operations outlined with respect to FIG- 
URE 2 and infomns the application program via the da- ; 
tabase manager 26 of the status of the database after 
recovery. 

The status of data in the recovered database can 
either be onsistent but old r inconsistent. A consist nt 
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status is typicaliy obtained when a recent backup file has 
been r baded from th image dump archive 20 and re- 
covery bg 22. Attematively» the database status may be 
inconsist nt if the backup files ar relatively old or if th 
system completely lost power. The consistency of the s 
data may be determined using for example checksum 
error detection techniques where checksums are calcu- 
lated at each dump and at reload for structure oitorma- 
tion of the database, e.g.. record addresses, numbers 
of instances, allocated memory, etc. If the checksums io 
match after a reload, the transient data are consistent. 
However, if the checksums do not match, the recovery 
processor 24 may inform the application that the data- 
base is inconsistent, and the applicatbn must restore 
the transient part of the database using information oth- is 
er than that currently stored in the datat)ase. 

FIGURE 4 illustrates in time-lina format varbus 
transaction categories whbh may have to be dealt with 
in the event of a system failure. Database transactions 
relating to semi-pemnanent data entries in the first sec- 20 
tion of memory are shown as semi-permanent transac- 
tions ST1 -ST5. At time T^. a checkpoint memory dump 
occurs. At Tf, a system failure occurs. Semi-pemianent 
transaction ST1 is completed before the checkpoint T^, 
and therefore, is readily recovered when the archive 2S 
copy of the database is re loaded from persistent storage 
into the non-persistent database. Semi-permanent 
transaction ST2 started prbr to checkpoint time com- 
pleted after the checkpoint time but before the sys- 
tem failure time Tf. Semi-permanent transaction ST3 al- so 
eo started prior to the checkpoint time but did not com- 
plete before the system failure. Semi-permanent data 
transaction ST4 started after the checkpoint but was 
completed before system failure. Finally, semi-perma- 
nent data transactbn ST5 also started after the check- 3S 
point time, but was not completed by the system failure. 

From the time-line drawing in FIGURE 4, one may 
understand that uncompleted transactions ST3 and ST5 
must be "undone* by the database manager 26. Trans- 
actlorts ST2 and ST4 must be "redone" because even 40 
though these transactbrw were completed before the 
system failure, they were not output on the most recent 
dump to persistent storage. Once the recovery proces- 
sor 24 bentifies transactions ST2-ST5. it determines 
which transactions must be undone and which must be ^ 
redone using the undo-list and redo-let technique de- 
scribed in the background section above. 

FIGURE 5 illustrates an example time tine of data- 
base transactions during a system failure and recovery. 
At time T^, a checkpoint copy is made of the seml-per- so 
manent data stored in the first nriemory section 1 4 of the 
primary store database 10. Various database transac- 
tion updates occur between the checkpoint time T^ and 
the system failure time Tf. Only the transactbns ST1 , 
ST3. and ST5 relating to semi-permanent data are ss 
logged. Transient data trEunsactions TT2 and TT4 are 
not logged. 

After the yetem failur at failure time Tf, the recov- 



ery process begins and the system starts to reload. At 
recovery time Tp the rebad is completed, and the data 
handling and storage system begins operating again. At 
start time T^ with the system restarted, the bg is xe- 
cut d, and at op railed tim T^, normal op ration of the 
data handling and storage system is restored. 

Because the database transaction T6 occurs be- 
tween failure Tf and start T^, it is not recorded and there- 
fore is effectively bst. As described above, the time 
when the system starts to accept transient data trans- 
actions is shifted from operatbn time T^ to the earlier 
start time Tg. However, if transient dteita are updated after 
the loading the of database copy from the persistent 
storage archive into the first section of the database, 
those transient data updates, represented in FIGURE 5 
by transaction T7, are In fact registered in the transient 
data, second portion of the database. This earlier reg- 
istration of new database transactions is significant. If 
conventional logging type recovery techniques were 
simply used, database transactions such as transaction 
T7 which occur between time and T^ woub be bst. 

The present invention, by reducing the time period 
of database recovery relating to copying archived data 
from persistent memory to non-persistent database, re- 
duces the number of lost transactions that occur during 
that recovery time period is reduced. In addition, data- 
base transactions which relate specifically to rapidly 
changing transient data may be registered before the 
"normal* operatic^ of the semi-permanent data portion 
of the primary store database is restored, i.e., after the 
undoing, redoing, and log restoration procedures re- 
quired for semi-permanent data. The size of bg files In 
persistent memory (and in temporary log buffers in pri- 
nnary store 1 0) may be reduced because transient trans- 
actions are not logged. 

The present Invention is also advantageous in ap- 
plicatbns like intelligent networks which monitor huge 
amounts of data. Because this data is typically backed 
up at a managing eite. the intelligent network may ord r 
a separate recovery orchestrated by that managing site 
if it detects that the data (semi-permanent and/or tran- 
sient) is corrupted. Because of that external backup, it 
is not necessary for the database to store such large 
quantities of data on the periodic checkpoint dumps, ir- 
respective of whether the data are semi-permanent or 
transient 

FIGURE 6 illustrates in flow chart format a routine 
for updating a database in accordance with the present 
invention. A decision is made at block 52 whether a da- 
tabase transaction update has just been received. If so, 
a second decision is made in block 54 to determine the 
type of the just received database transactbn. If the type 
of transactbn relates to semi-permanent data, that da- 
tabase trEuisactbn is stored in the log buffer section 1B 
of the primary store 10 (block 56). That transactbn is 
also stored in the first database memory section 14 
(block 58). A decision is made in block 60 whether ttie 
log buffer is full rif it is time to dump the bg top reistent 
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media. If not, cohtrol returns to check for receipt of an- 
other database transaction. Otherwise, the log informa- 
tion is stored on persistent media (block 64). 

Ifthedatabas transaction r lates to transient data, 
that database transaction is stor d in the second mem- 
ory section 16 of prinrtary store 10 (block 62). A decision 
is made after execution of blocks 62 or 64 whether it is 
time for a checkpoint dunnp (block 66). and If not. control 
returns to wait for receipt of the next database transac- 
tion. Otherwise, the semi-permanent data stored in first 
memory section 1 4 (and possibly the transient data in 
the second menru>ry section 16 in an attemative embod- 
iment) are dumped into persistent media (btock 68). 

FIGURE 7 illustrates a recovery routine (block 80) 
which may be used to recover the database handling 
and storage system from system fault or failure in ac- 
cordance with the present invention. A decision is made 
in block 82 whether a system failure has occurred. If a 
failure has occurred, the recovery processor optionally 
clears/resets the first menrK)ry section 14 of the primary 
store 10 (block 84). However, the second memory sec- 
tion 16 of the primary store 10 for storing transient type 
data is left untouched. The image copy of the semi-per- 
nnanent data from persistent storage from the wosX re- 
cent checkpoint dump is copied Into the first memory 
section 14 (block 86), The recovery processor further 
recovers database transactions relating to semi-perma- 
nent data which have occurred since the most recent 
checkpoint using the log information from persistent log 
22 (block 88). The recovery processor checks the tran- 
sient data in the second section 16 of the primary store 
10 (block 90). A decision Is made in block 92 whether 
that data is consistent. If it is. the application continues, 
and further updates to that data are received (block 94). 
Otherwise, the data are inconsistent, and must be re- 
covered from sources other than the database system 
(block 96) or in the alternative embodiment, an image 
copy of transient data from persistent storage from the 
most recent checkpoint dump is copied into the second 
memory section 16). 

One particular application of the present invention 
is to mobile telephony systems that manage a large da- 
tabase of mobile subscribers. The mobile telephony ap- 
plication designates certain database records according 
to type, e.g.. as semi-permanent or transient. In general, 
a mobile subscriber profile, including the subscriber's 
identification, his telephone number, additional telepho- 
ny services to which that particular subscriber sub- 
scribes, etc.. changes infrequently or not at all. In con- 
trast, a roaming mobile telephone (i.e., a subscriber 
travelling in an automobile between various cellular tel- 
ephone "cells') may register a new cell kscation very fre- 
quently. Data relating to a subscriber's current location 
may be declared by the mobile telephony application as 
transisnt data. Thus, when a mobile subscriber changes 
his location, his new location Is simply registered In the 
transient section of the database but not logged. If such 
mobile subscriber location changes were logged using 



conventional logging techniques, the logging files wouki 
be huge. Moreover, the amount of time required to re- 
cover such large bgging files after a system failure 
would be quite extended with potentially many database 
s transaction updat s occurring during that extended re- 
covery process being lost. Those mobiles whose trans- 
action updates are not recorded during extended recov- 
ery are then "lost'from the perspective of the subscriber 
database. 

The mobile telephony application in accordance 
with the present inventbn recognizes that this mobile 
location type data is suitable for designatk>n as transient 
type data because it changes very frequently. Altema- 
tively and/or additionally, data which can be tolerated by 
the application as inconsistent data may also be appro- 
priately designated as transient. Since the transient data 
are not dumped or logged, they are assumed to be con- 
sistent - a good assumption In certain types of system 
failures. Otherwise or in addition, the application must 
handle the Inconsistency of that transient data. 

In the case of changing mobile telephone locations, 
mobile subscribers frequently and automatically send in 
registration messages to the mobile telephony applica- 
tion which may be used by the application to restore cur- 
rent database values or correct data values for incon- 
sistent transient data. Alternatively, the mobile telepho- 
ny application could broadcast a localization order to all 
mobile subscribers requiring them to report in their cur- 
rent location which would then be used to restore the 
database. Another attemative would be to use applica- 
tion files external to the database. Such applicatk>n fil s 
(which may be quite large) can be stored in memory Irv 
dependent of the database system. In this situation, 
such large amounts of data (which may or may not 
change rapidly), may be defined as transient because 
the application has an easy mechanism by which to re- 
store the database in the event a system failure renders 
that transient data inconsistent, such as the intelligent 
network example described above. This is another ex- 
ample of how the amount of data which has to be ar- 
chived and logged by the database system may be re- 
duced using the present invention. 

While the invention has been described in connec- 
tion with what is presently considered to be the most 
practical and preferred embodiment, it is to be under- 
stood that the invention is not to be limited to the dis- 
closed embodiment, but on the contrary, is intended to 
cover various modifications and equivalent arrange- 
ments included within the spirit and scope of the ap- 
pended claims. 



Claims 

ss 1 . An electronic data storage and processing system, 
comprising: 

nonpersistent memory for storing a database 
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including first and second sections correspond- 
ing to first and second typ s of data; 
first persistent memory for storing a c py of da- 
ta curr ntlyst red in the first section; 
s cond persistent memory for logging data- ^ 
base transactions: and 

a data processor copying the first type of data 
stored in the first section into the first persistent 
memory at checkpoint time periods and logging 
in the second persistent memory only those da- to 
tabase transactions relating to the first type of 
data stored in the first section that occur after 
a most recent checkpoint, 
wherein transactions relating to the second 
type of data stored in the second portion are is 
not logged. 

2. The system in claim 1 , wherein the data processor 
stores only data from the first section in the first per- 
sistent mennory at each checkpoint. 

3. The system in claim 1 , wherein the data processor 
stores data from both the first and second sections 
in the first persistent memory at each checkpoint. 

25 

4. The system in claim 1 , wherein the first type of data 
are semi-permanent data that usually change over 
a time period greater than the checkpoint time pe- 
riods and the second type of data are transient data 
that change more frequently than the first type of so 
data. 
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ond type of data in the database recovers consist- 
ent data for storage in the second section. 

7. The system in daim 5, wh rein the first p rsistent 
memory stores a copy of the second type of data 
stored in th s^Kindm mory section and the data- 
base manager determines the consistency of the 
second type of data stored in the second section, 
and wherein if the data in the second memory sec- 
tion IS inconsistent, the database manager copies 
the second type of data stored In the first persistent 
memory into the second section of nonpersistent 
memory. 

8. The system in claim 5, wherein the non-persistent 
memory Includes a third section for buffering recent 
database transactions relating to data in the first 
section and the database manager stores in the 
third section only those transactions relating to the 
first type of data stored In the first sectkan that occur 
after a most recent checkpoint, with tiansacttons re- 
lating to the second type of data stored in the sec- 
ond eection not being buffered in the third section. 

9. The system in claim B, further comprising: 

a second persistent memory for togging the 
buffered transactions, wherein the recovery proces- 
sor recovers only the first type of data for the first 
section from the system failure using the logged 
transactions stored in the second persistent mem- 
ory. 



5. An electronic data storage and processing system, 
comprising: 

35 

nonpersistent memory for storing a database 
Including first and second sections correspond- 
ing to first and second types of data; 
first persistent memory for storing a copy of the 
first type of data stored In the first memory sec- 40 
Xk>n: 

a system manager copying data stored in the 

first section into the first persistent memory at 

checkpoint time periods; and 

a recovery processor for recovering from a sys- 4S 

tem failure by copying the first type of data from 

the first persistent memory into the first sectksn 

of the nonpersistent menrtory, 

wherein the recovery processor leaves the data 

in the second section of the nonpersistent so 

memory in the state that data exists after the 

failure. 

6. The system in claim 5, wherein the database man- 
ager determines the consistency of the second type ss 
ot data stored in the second sectbn. and if the sec- 
ond type of data stored In the second section is in- 
consistent, an application program using the soc- 



10. The system In claim 5, further comprising: 

second persistent memory for logging only 
those transactions relating to the first type of data 
that occur after a most recent checkpoint, with 
transactions relating to the second type of data not 
being bgged in the second persistent memory. 

1 1 . The system in claim 5. wherein the first type of data 
are semi-permanent data that usually changes only 
over a time period greater than the checkpoint time 
Interval and the second type of data are transient 
data that changes more frequently than the first type 
of data. 

1 2. A method for managing a data handling system that 
includes nonpersistent memory for storing a data- 
base and persistent memory, comprising the steps 
of: 

storing database transactions relating to a first 
type of data in a first sectkm of the non-persist- 
ent memory; 

storing database transactions relating to a sec- 
ond type ot data in a second section of the nor^ 
persistent memory; 

copying the first type of data in the first eection 
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at predetermined checkpoint time intervals into 
the persistent memory; 

storing in the persistent memory only those da- 
tabase transactions affecting the first type f 
data stored in the first section that occur after 
a recent checkpoint time interval, 
wherein database transactions affecting the 
second type of data stored in the second sec- 
tion are not stored in the persistent memory.. 

13. The method in claim 12, wherein only the first type 
of data in the first section of the non-persistent 
memory are stored in the persistent memory at each 
checkpoint. 

14. The method In claim 12, wherein data in both the 
first and second sections of the non-persistent 
memory are stored in the persistent memory at each 
checkpoint. 

15. The method in claim 12, wherein the first type of 
data are seml-pemianent data that usually change 
only over a time period greater than the checkpoint 
time Intervals and the second type of data are tran- 
sient data that change more frequently than the first 
type of data. 

16. A method for recovering an electronic data storage 
and processing system from a system failure, com- 
prising the steps of: 

storing in nonperslstent memory a database 
having first and second sections corresponding 
to first and second types of data; 
transferring the first type of data stored in the 
first section into a first persistent memory at 
checkpoint time periods; and 
recovering from a system failure by k>ading the 
first type of data from the first persistent mem- 
ory into the first section of the database after 
the failure and leaving the second type of data 
In the second section of the database in a state 
that second type of data exists after the failure. 

17. The method in claim 16, further comprising: 

logging only database transactions relating to 
the first type of cteita in the first section, and 
storing in a third section of the database only 
transactions relating to the first type of data 
stored in the first section that occur after a re- 
cent checkpoint and not storing in the third sec- 
tion transactions relating to the second type of 
data stored in the second sectksn. 
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type of data stored in the first section that occur after 
a most recent ch ckp int. 

19. The method in claim 18, further comprising: 

recovering only the first typ f data for the 
first section from the system failur using the trans- 
actions stored in the persistent mennory. 

20. The nnethod in claim 16, wherein the first type of 
data are semi-permanent data that usually change 
only over a time period greater than the checkpoint 
time intervals and the second type of data are tran- 
sient cteAa that change more frequently than the first 
type of cteta. 
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18, The method in claim 17. further comprising: 

transferring from the third section into the per- 
sistent memory only transact! ns relating to the first 
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